>   This may have been true 10 years ago.

But I wasn't programming games 10 years ago.

>   Current compilers can usually optimize the overhead (eg. the function
> call) away completely (supposing the operator function is inline).

Couldn't compilers inline functions 10 years ago?

Anyway, my point isn't just the function call overhead, it's the fact that it's
not an operator internally supported by the compiler with a bunch of rules, it's
a series of instructions of unspecified length elsewhere.

> If you make a class which uses operator overloading for simple tasks
> (such as adding two internal values together) you should definitely
> make them inline, after which the compiler will be able to optimize
> all the overhead away.

Well, it can lose the function call overhead, but not the overhead of it being a
function (i.e. several instructions) rather than a simple instruction (which is
really my point).

What I'm saying is I want "+" to produce the same amount of assembler code
whenever I use it.

>   For example, suppose you have this (in C++):

Aha! but you'd never define an object for a type inherently supported by the
compiler, only for types which require something more complex. So you end up
with "+" becoming different amounts of compiled code depending on the context in
which it's used. This makes it harder to optimise code, since it is harder to
keep track of where the more complex + functions are being invoked.

Plus when someone is writing the code if they have to call
PerformReallySlowAndComplicatedAddition( a, b ) rather than a+b it tends to make
people more aware of what they're doing. It doesn't completely solve the problem
of writing optimised code, I'm just saying it makes it easier to keep track of
what's actually going on at the lowest level.

>   So using a class with operator overloading did not ask any overhead
> *at all* to the code.

I think you've missed my point, I'm not saying operator overloading does
anything different to function calls, I'm saying addition functions for two
matrices are different to addition functions for the processor's inbuilt types,
and it is useful when optimising to keep track of this difference.

Operator overloading is great if you want to code at a higher level without
being bogged down by thinking about what's happening at the lowest level, but
when optimising code you want to do the opposite! Heck, if were even remotely
feasible we'd write everything in assembler...

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message